home *** CD-ROM | disk | FTP | other *** search
Text File | 1994-08-02 | 36.5 KB | 1,509 lines |
-
-
- Network Working Group J. Reynolds
- Request for Comments: 880 J. Postel
- ISI
- Obsoletes: RFC 840 October 1983
-
-
- OFFICIAL PROTOCOLS
-
-
- This RFC identifies the documents specifying the official protocols used
- in the Internet. Annotations identify any revisions or changes planned.
-
- To first order, the official protocols are those in the "Internet
- Protocol Transition Workbook" (IPTW) dated March 1982. There are
- several protocols in use that are not in the IPTW. A few of the
- protocols in the IPTW have been revised. Notably, the mail protocols
- have been revised and issued as a volume titled "Internet Mail
- Protocols" dated November 1982. Telnet and the most useful option
- protocols were issued by the NIC in a booklet entitled "Internet Telnet
- Protocol and Options" (ITP), dated June 1983. Some protocols have not
- been revised for many years, these are found in the old "ARPANET
- Protocol Handbook" (APH) dated January 1978. There is also a volume of
- protocol related information called the "Internet Protocol Implementers
- Guide" (IPIG) dated August 1982.
-
- This document is organized as a sketchy outline. The entries are
- protocols (e.g., Transmission Control Protocol). In each entry there
- are notes on status, specification, comments, other references,
- dependencies, and contact.
-
- The status is one of: required, recommended, elective, or
- experimental.
-
- The specification identifies the protocol defining documents.
-
- The comments describe any differences from the specification or
- problems with the protocol.
-
- The other references identify documents that comment on or expand on
- the protocol.
-
- The dependencies indicate what other protocols are called upon by
- this protocol.
-
- The contact indicates a person who can answer questions about the
- protocol.
-
-
-
-
-
-
-
-
- Reynolds & Postel [Page 1]
-
-
-
- Official Protocols RFC 880
-
-
- In particular, the status may be:
-
- required
-
- - all hosts must implement the required protocol,
-
- recommended
-
- - all hosts are encouraged to implement the recommended
- protocol,
-
- elective
-
- - hosts may implement or not the elective protocol,
-
- experimental
-
- - hosts should not implement the experimental protocol unless
- they are participating in the experiment and have coordinated
- their use of this protocol with the contact person, and
-
- none
-
- - this is not a protocol.
-
- Overview
-
- Catenet Model ------------------------------------------------------
-
- STATUS: None
-
- SPECIFICATION: IEN 48 (in IPTW)
-
- COMMENTS:
-
- Gives an overview of the organization and principles of the
- Internet.
-
- Could be revised and expanded.
-
- OTHER REFERENCES:
-
- RFC 871 - A Perspective on the ARPANET Reference Model
-
- DEPENDENCIES:
-
- CONTACT: Postel@USC-ISIF
-
-
-
-
- Reynolds & Postel [Page 2]
-
-
-
- Official Protocols RFC 880
-
-
- Network Level
-
- Internet Protocol (IP) ---------------------------------------------
-
- STATUS: Required
-
- SPECIFICATION: RFC 791 (in IPTW)
-
- COMMENTS:
-
- This is the universal protocol of the Internet. This datagram
- protocol provides the universal addressing of hosts in the
- Internet.
-
- A few minor problems have been noted in this document.
-
- The most serious is a bit of confusion in the route options.
- The route options have a pointer that indicates which octet of
- the route is the next to be used. The confusion is between the
- phrases "the pointer is relative to this option" and "the
- smallest legal value for the pointer is 4". If you are
- confused, forget about the relative part, the pointer begins
- at 4.
-
- Another important point is the alternate reassembly procedure
- suggested in RFC 815.
-
- Note that ICMP is defined to be an integral part of IP. You
- have not completed an implementation of IP if it does not
- include ICMP.
-
- OTHER REFERENCES:
-
- RFC 815 (in IPIG) - IP Datagram Reassembly Algorithms
-
- RFC 814 (in IPIG) - Names, Addresses, Ports, and Routes
-
- RFC 816 (in IPIG) - Fault Isolation and Recovery
-
- RFC 817 (in IPIG) - Modularity and Efficiency in Protocol
- Implementation
-
- DEPENDENCIES:
-
- CONTACT: Postel@USC-ISIF
-
-
-
-
-
-
- Reynolds & Postel [Page 3]
-
-
-
- Official Protocols RFC 880
-
-
- Internet Control Message Protocol (ICMP) ---------------------------
-
- STATUS: Required
-
- SPECIFICATION: RFC 792 (in IPTW)
-
- COMMENTS:
-
- The control messages and error reports that go with the
- Internet Protocol.
-
- A few minor errors in the document have been noted.
- Suggestions have been made for additional types of redirect
- message and additional destination unreachable messages.
-
- Note that ICMP is defined to be an integral part of IP. You
- have not completed an implementation of IP if it does not
- include ICMP.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Internet Protocol
-
- CONTACT: Postel@USC-ISIF
-
- Host Level
-
- User Datagram Protocol (UDP) ---------------------------------------
-
- STATUS: Recommended
-
- SPECIFICATION: RFC 768 (in IPTW)
-
- COMMENTS:
-
- Provides a datagram service to applications. Adds port
- addressing to the IP services.
-
- The only change noted for the UDP specification is a minor
- clarification that if in computing the checksum a padding octet
- is used for the computation it is not transmitted or counted in
- the length.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Internet Protocol
-
- CONTACT: Postel@USC-ISIF
-
-
-
- Reynolds & Postel [Page 4]
-
-
-
- Official Protocols RFC 880
-
-
- Transmission Control Protocol (TCP) --------------------------------
-
- STATUS: Recommended
-
- SPECIFICATION: RFC 793 (in IPTW)
-
- COMMENTS:
-
- Provides reliable end-to-end data stream service.
-
- Many comments and corrections have been received for the TCP
- specification document. These are primarily document bugs
- rather than protocol bugs.
-
- Event Processing Section: There are many minor corrections and
- clarifications needed in this section.
-
- Push: There are still some phrases in the document that give a
- "record mark" flavor to the push. These should be further
- clarified. The push is not a record mark.
-
- Listening Servers: Several comments have been received on
- difficulties with contacting listening servers. There should
- be some discussion of implementation issues for servers, and
- some notes on alternative models of system and process
- organization for servers.
-
- Maximum Segment Size: The maximum segment size option should
- be generalized and clarified. It can be used to either
- increase or decrease the maximum segment size from the default.
- The default should be established more clearly. The default is
- based on the default maximum Internet Datagram size which is
- 576 octets counting the IP and TCP headers. The option counts
- only the segment data. For each of IP and TCP the minimum
- header is 20 octets and the maximum header is 60 octets. So the
- default maximum data segment is could be anywhere from 456 to
- 536 octets. The current proposal is to set it at 536 data
- octets.
-
- Idle Connections: There have been questions about
- automatically closing idle connections. Idle connections are
- ok, and should not be closed. There are several cases where
- idle connections arise, for example, in Telnet when a user is
- thinking for a long time following a message from the server
- computer before his next input. There is no TCP "probe"
- mechanism, and none is needed.
-
- Queued Receive Data on Closing: There are several points where
- it is not clear from the description what to do about data
-
-
- Reynolds & Postel [Page 5]
-
-
-
- Official Protocols RFC 880
-
-
- received by the TCP but not yet passed to the user,
- particularly when the connection is being closed. In general,
- the data is to be kept to give to the user if he does a RECV
- call.
-
- Out of Order Segments: The description says that segments that
- arrive out of order, that is, are not exactly the next segment
- to be processed, may be kept on hand. It should also point out
- that there is a very large performance penalty for not doing
- so.
-
- User Time Out: This is the time out started on an open or send
- call. If this user time out occurs the user should be
- notified, but the connection should not be closed or the TCB
- deleted. The user should explicitly ABORT the connection if he
- wants to give up.
-
- OTHER REFERENCES:
-
- RFC 813 (in IPIG) - Window and Acknowledgement Strategy in TCP
-
- RFC 814 (in IPIG) - Names, Addresses, Ports, and Routes
-
- RFC 816 (in IPIG) - Fault Isolation and Recovery
-
- RFC 817 (in IPIG) - Modularity and Efficiency in Protocol
- Implementation
-
- DEPENDENCIES: Internet Protocol
-
- CONTACT: Postel@USC-ISIF
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Reynolds & Postel [Page 6]
-
-
-
- Official Protocols RFC 880
-
-
- Host Monitoring Protocol (HMP) -------------------------------------
-
- STATUS: Elective
-
- SPECIFICATION: IEN 197
-
- COMMENTS:
-
- This is a good tool for debugging protocol implementations in
- small remotely located computers.
-
- This protocol is used to monitor Internet gateways and the
- TACs.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Internet Protocol
-
- CONTACT: Hinden@BBN-UNIX
-
- Cross Net Debugger (XNET) ------------------------------------------
-
- STATUS: Elective
-
- SPECIFICATION: IEN 158
-
- COMMENTS:
-
- A debugging protocol, allows debugger like access to remote
- systems.
-
- This specification should be updated and reissued as an RFC.
-
- OTHER REFERENCES:
-
- RFC 643
-
- DEPENDENCIES: Internet Protocol
-
- CONTACT: Postel@USC-ISIF
-
-
-
-
-
-
-
-
-
-
-
- Reynolds & Postel [Page 7]
-
-
-
- Official Protocols RFC 880
-
-
- Exterior Gateway Protocol (EGP) ------------------------------------
-
- STATUS: Experimental
-
- SPECIFICATION: RFC 827
-
- COMMENTS:
-
- The gateway protocol now under development.
-
- Please discuss any plans for implementation or use of this
- protocol with the contact.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Internet Protocol
-
- CONTACT: Mills@USC-ISID
-
- Gateway Gateway Protocol (GGP) -------------------------------------
-
- STATUS: Experimental
-
- SPECIFICATION: RFC 823
-
- COMMENTS:
-
- The gateway protocol now used in the core gateways.
-
- Please discuss any plans for implementation or use of this
- protocol with the contact.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Internet Protocol
-
- CONTACT: Brescia@BBN-UNIX
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Reynolds & Postel [Page 8]
-
-
-
- Official Protocols RFC 880
-
-
- Multiplexing Protocol (MUX) ----------------------------------------
-
- STATUS: Experimental
-
- SPECIFICATION: IEN 90
-
- COMMENTS:
-
- Defines a capability to combine several segments from different
- higher level protocols in one IP datagram.
-
- No current experiment in progress. There is some question as
- to the extent to which the sharing this protocol envisions can
- actually take place. Also, there are some issues about the
- information captured in the multiplexing header being (a)
- insufficient, or (b) over specific.
-
- Please discuss any plans for implementation or use of this
- protocol with the contact.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Internet Protocol
-
- CONTACT: Postel@USC-ISIF
-
- Stream Protocol (ST) -----------------------------------------------
-
- STATUS: Experimental
-
- SPECIFICATION: IEN 119
-
- COMMENTS:
-
- A gateway resource allocation protocol designed for use in
- multihost real time applications.
-
- The implementation of this protocol has evolved and may no
- longer be consistent with this specification. The document
- should be updated and issued as an RFC.
-
- Please discuss any plans for implementation or use of this
- protocol with the contact.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Internet Protocol
-
- CONTACT: Forgie@BBN
-
-
- Reynolds & Postel [Page 9]
-
-
-
- Official Protocols RFC 880
-
-
- Network Voice Protocol (NVP-II) ------------------------------------
-
- STATUS: Experimental
-
- SPECIFICATION: RFC xxx
-
- COMMENTS:
-
- Defines the procedures for real time voice conferencing.
-
- The specification is an ISI Internal Memo which should be
- updated and issued as an RFC.
-
- Please discuss any plans for implementation or use of this
- protocol with the contact.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Internet Protocol, Stream Protocol
-
- CONTACT: Casner@USC-ISIB
-
- Application Level
-
- Telnet Protocol (TELNET) -------------------------------------------
-
- STATUS: Recommended
-
- SPECIFICATION: RFC 854 (in "Internet Telnet Protocol and
- Options")
-
- COMMENTS:
-
- The protocol for remote terminal access.
-
- This has been revised since the IPTW. RFC 764 in IPTW is now
- obsolete.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Transmission Control Protocol
-
- CONTACT: Postel@USC-ISIF
-
-
-
-
-
-
-
-
- Reynolds & Postel [Page 10]
-
-
-
- Official Protocols RFC 880
-
-
- Telnet Options (TELNET-OPTIONS) ------------------------------------
-
- STATUS: Elective
-
- SPECIFICATION: General description of options: RFC 855
- (in "Internet Telnet Protocol and Options")
-
- Number Name RFC NIC ITP APH USE
- ------ --------------------------------- --- ----- --- --- ---
- 0 Binary Transmission 856 ----- yes obs yes
- 1 Echo 857 ----- yes obs yes
- 2 Reconnection ... 15391 no yes no
- 3 Suppress Go Ahead 858 ----- yes obs yes
- 4 Approx Message Size Negotiation ... 15393 no yes no
- 5 Status 859 ----- yes obs yes
- 6 Timing Mark 860 ----- yes obs yes
- 7 Remote Controlled Trans and Echo 726 39237 no yes no
- 8 Output Line Width ... 20196 no yes no
- 9 Output Page Size ... 20197 no yes no
- 10 Output Carriage-Return Disposition 652 31155 no yes no
- 11 Output Horizontal Tabstops 653 31156 no yes no
- 12 Output Horizontal Tab Disposition 654 31157 no yes no
- 13 Output Formfeed Disposition 655 31158 no yes no
- 14 Output Vertical Tabstops 656 31159 no yes no
- 15 Output Vertical Tab Disposition 657 31160 no yes no
- 16 Output Linefeed Disposition 658 31161 no yes no
- 17 Extended ASCII 698 32964 no yes no
- 18 Logout 727 40025 no yes no
- 19 Byte Macro 735 42083 no yes no
- 20 Data Entry Terminal 732 41762 no yes no
- 21 SUPDUP 734 736 42213 no yes no
- 22 SUPDUP Output 749 45449 no no no
- 23 Send Location 779 ----- no no no
- 255 Extended-Options-List 861 ----- yes obs yes
-
- (obs = obsolete)
-
- The ITP column indicates if the specification is included in the
- Internet Telnet Protocol and Options. The APH column indicates if
- the specification is included in the ARPANET Protocol Handbook.
- The USE column of the table above indicates which options are in
- general use.
-
- COMMENTS:
-
- The Binary Transmission, Echo, Suppress Go Ahead, Status,
- Timing Mark, and Extended Options List options have been
- recently updated and reissued. These are the most frequently
- implemented options.
-
-
- Reynolds & Postel [Page 11]
-
-
-
- Official Protocols RFC 880
-
-
- The remaining options should be reviewed and the useful ones
- should be revised and reissued. The others should be
- eliminated.
-
- The following are recommended: Binary Transmission, Echo,
- Suppress Go Ahead, Status, Timing Mark, and Extended Options
- List.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Telnet
-
- CONTACT: Postel@USC-ISIF
-
- File Transfer Protocol (FTP) ---------------------------------------
-
- STATUS: Recommended
-
- SPECIFICATION: RFC 765 (in IPTW)
-
- COMMENTS:
-
- The protocol for moving files between Internet hosts. Provides
- for access control and negotiation of file parameters.
-
- There are a number of minor corrections to be made. A major
- change is the deletion of the mail commands, and a major
- clarification is needed in the discussion of the management of
- the data connection. Also, a suggestion has been made to
- include some directory manipulation commands (RFC 775).
-
- Even though the MAIL features are defined in this document,
- they are not to be used. The SMTP protocol is to be used for
- all mail service in the Internet.
-
- Data Connection Management:
-
- a. Default Data Connection Ports: All FTP implementations
- must support use of the default data connection ports, and
- only the User-PI may initiate the use of non-default ports.
-
- b. Negotiating Non-Default Data Ports: The User-PI may
- specify a non-default user side data port with the PORT
- command. The User-PI may request the server side to
- identify a non-default server side data port with the PASV
- command. Since a connection is defined by the pair of
- addresses, either of these actions is enough to get a
- different data connection, still it is permitted to do both
-
-
-
- Reynolds & Postel [Page 12]
-
-
-
- Official Protocols RFC 880
-
-
- commands to use new ports on both ends of the data
- connection.
-
- c. Reuse of the Data Connection: When using the stream
- mode of data transfer the end of the file must be indicated
- by closing the connection. This causes a problem if
- multiple files are to be transfered in the session, due to
- need for TCP to hold the connection record for a time out
- period to guarantee the reliable communication. Thus the
- connection can not be reopened at once.
-
- There are two solutions to this problem. The first is to
- negotiate a non-default port (as in (b) above). The
- second is to use another transfer mode.
-
- A comment on transfer modes. The stream transfer mode is
- inherently unreliable, since one can not determine if the
- connection closed prematurely or not. The other transfer
- modes (Block, Compressed) do not close the connection to
- indicate the end of file. They have enough FTP encoding
- that the data connection can be parsed to determine the
- end of the file. Thus using these modes one can leave
- the data connection open for multiple file transfers.
-
- Why this was not a problem with the old NCP FTP:
-
- The NCP was designed with only the ARPANET in mind.
- The ARPANET provides very reliable service, and the
- NCP counted on it. If any packet of data from an NCP
- connection were lost or damaged by the network the NCP
- could not recover. It is a tribute to the ARPANET
- designers that the NCP FTP worked so well.
-
- The TCP is designed to provide reliable connections
- over many different types of networks and
- interconnections of networks. TCP must cope with a
- set of networks that can not promise to work as well
- as the ARPANET. TCP must make its own provisions for
- end-to-end recovery from lost or damaged packets.
- This leads to the need for the connection phase-down
- time-out. The NCP never had to deal with
- acknowledgements or retransmissions or many other
- things the TCP must do to make connection reliable in
- a more complex world.
-
- LIST and NLST:
-
- There is some confusion about the LIST an NLST commands, and
- what is appropriate to return. Some clarification and
-
-
- Reynolds & Postel [Page 13]
-
-
-
- Official Protocols RFC 880
-
-
- motivation for these commands should be added to the
- specification.
-
- OTHER REFERENCES:
-
- RFC 678 - Document File Format Standards
-
- DEPENDENCIES: Transmission Control Protocol
-
- CONTACT: Postel@USC-ISIF
-
- Trivial File Transfer Protocol (TFTP) ------------------------------
-
- STATUS: Elective
-
- SPECIFICATION: RFC 783 (in IPTW)
-
- COMMENTS:
-
- A very simple file moving protocol, no access control is
- provided.
-
- No known problems with this specification. This is in use in
- several local networks.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: User Datagram Protocol
-
- CONTACT: Postel@USC-ISIF
-
- Simple Mail Transfer Protocol (SMTP) -------------------------------
-
- STATUS: Recommended
-
- SPECIFICATION: RFC 821 (in "Internet Mail Protocols")
-
- COMMENTS:
-
- The procedure for transmitting computer mail between hosts.
-
- This has been revised since the IPTW, it is in the "Internet
- Mail Protocols" volume of November 1982. RFC 788 (in IPTW) is
- obsolete.
-
- There have been many misunderstandings and errors in the early
- implementations. Some documentation of these problems can be
- found in the file [ISIF]<SMTP>MAIL.ERRORS.
-
-
-
- Reynolds & Postel [Page 14]
-
-
-
- Official Protocols RFC 880
-
-
- Some minor differences between RFC 821 and RFC 822 should be
- resolved.
-
- OTHER REFERENCES:
-
- RFC 822 - Mail Header Format Standards
-
- This has been revised since the IPTW, it is in the "Internet
- Mail Protocols" volume of November 1982. RFC 733 (in IPTW)
- is obsolete. Further revision of RFC 822 is needed to
- correct some minor errors in the details of the
- specification.
-
- DEPENDENCIES: Transmission Control Protocol
-
- CONTACT: Postel@USC-ISIF
-
- Remote Job Entry (RJE) ---------------------------------------------
-
- STATUS: Elective
-
- SPECIFICATION: RFC 407 (in APH)
-
- COMMENTS:
-
- The general protocol for submitting batch jobs and retrieving
- the results.
-
- Some changes needed for use with TCP.
-
- No known active implementations.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: File Transfer Protocol
- Transmission Control Protocol
-
- CONTACT: Postel@USC-ISIF
-
-
-
-
-
-
-
-
-
-
-
-
-
- Reynolds & Postel [Page 15]
-
-
-
- Official Protocols RFC 880
-
-
- Remote Job Service (NETRJS) ----------------------------------------
-
- STATUS: Elective
-
- SPECIFICATION: RFC 740 (in APH)
-
- COMMENTS:
-
- A special protocol for submitting batch jobs and retrieving the
- results used with the UCLA IBM OS system.
-
- Please discuss any plans for implementation or use of this
- protocol with the contact.
-
- Revision in progress.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Transmission Control Protocol
-
- CONTACT: Braden@USC-ISIA
-
- Remote Telnet Service (RTELNET) ------------------------------------
-
- STATUS: Elective
-
- SPECIFICATION: RFC 818
-
- COMMENTS:
-
- Provides special access to user Telnet on a remote system.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Telnet, Transmission Control Protocol
-
- CONTACT: Postel@USC-ISIF
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Reynolds & Postel [Page 16]
-
-
-
- Official Protocols RFC 880
-
-
- Graphics Protocol (GRAPHICS) ---------------------------------------
-
- STATUS: Elective
-
- SPECIFICATION: NIC 24308 (in APH)
-
- COMMENTS:
-
- The protocols for vector graphics.
-
- Very minor changes needed for use with TCP.
-
- No known active implementations.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Telnet, Transmission Control Protocol
-
- CONTACT: Postel@USC-ISIF
-
- Echo Protocol (ECHO) -----------------------------------------------
-
- STATUS: Recommended
-
- SPECIFICATION: RFC 862
-
- COMMENTS:
-
- Debugging protocol, sends back whatever you send it.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Transmission Control Protocol
- or User Datagram Protocol
-
- CONTACT: Postel@USC-ISIF
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Reynolds & Postel [Page 17]
-
-
-
- Official Protocols RFC 880
-
-
- Discard Protocol (DISCARD) -----------------------------------------
-
- STATUS: Elective
-
- SPECIFICATION: RFC 863
-
- COMMENTS:
-
- Debugging protocol, throws away whatever you send it.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Transmission Control Protocol
- or User Datagram Protocol
-
- CONTACT: Postel@USC-ISIF
-
- Character Generator Protocol (CHARGEN) -----------------------------
-
- STATUS: Elective
-
- SPECIFICATION: RFC 864
-
- COMMENTS:
-
- Debugging protocol, sends you ASCII data.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Transmission Control Protocol
- or User Datagram Protocol
-
- CONTACT: Postel@USC-ISIF
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Reynolds & Postel [Page 18]
-
-
-
- Official Protocols RFC 880
-
-
- Quote of the Day Protocol (QUOTE) ----------------------------------
-
- STATUS: Elective
-
- SPECIFICATION: RFC 865
-
- COMMENTS:
-
- Debugging protocol, sends you a short ASCII message.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Transmission Control Protocol
- or User Datagram Protocol
-
- CONTACT: Postel@USC-ISIF
-
- Active Users Protocol (USERS) --------------------------------------
-
- STATUS: Elective
-
- SPECIFICATION: RFC 866
-
- COMMENTS:
-
- Lists the currently active users.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Transmission Control Protocol
- or User Datagram Protocol
-
- CONTACT: Postel@USC-ISIF
-
- Finger Protocol (FINGER) -------------------------------------------
-
- STATUS: Elective
-
- SPECIFICATION: RFC 742 (in APH)
-
- COMMENTS:
-
- Provides information on the current or most recent activity of
- a user.
-
- Some extensions have been suggested.
-
- Some changes are are needed for TCP.
-
-
-
- Reynolds & Postel [Page 19]
-
-
-
- Official Protocols RFC 880
-
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Transmission Control Protocol
-
- CONTACT: Postel@USC-ISIF
-
- NICNAME Protocol (NICNAME) -----------------------------------------
-
- STATUS: Elective
-
- SPECIFICATION: RFC 812 (in IPTW)
-
- COMMENTS:
-
- Accesses the ARPANET Directory database. Provides a way to
- find out about people, their addresses, phone numbers,
- organizations, and mailboxes.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Transmission Control Protocol
-
- CONTACT: Feinler@SRI-NIC
-
- HOSTNAME Protocol (HOSTNAME) ---------------------------------------
-
- STATUS: Elective
-
- SPECIFICATION: RFC 811 (in IPTW)
-
- COMMENTS:
-
- Accesses the Registered Internet Hosts database (HOSTS.TXT).
- Provides a way to find out about a host in the Internet, its
- Internet Address, and the protocols it implements.
-
- OTHER REFERENCES:
-
- RFC 810 - Host Table Specification
-
- DEPENDENCIES: Transmission Control Protocol
-
- CONTACT: Feinler@SRI-NIC
-
-
-
-
-
-
-
-
- Reynolds & Postel [Page 20]
-
-
-
- Official Protocols RFC 880
-
-
- Host Name Server Protocol (NAMESERVER) -----------------------------
-
- STATUS: Experimental
-
- SPECIFICATION: IEN 116 (in IPTW)
-
- COMMENTS:
-
- Provides machine oriented procedure for translating a host name
- to an Internet Address.
-
- This specification has significant problems: 1) The name
- syntax is out of date. 2) The protocol details are ambiguous,
- in particular, the length octet either does or doesn't include
- itself and the op code. 3) The extensions are not supported by
- any known implementation.
-
- Work is in progress on a significant revision. Further
- implementations of this protocol are not advised.
-
- Please discuss any plans for implementation or use of this
- protocol with the contact.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: User Datagram Protocol
-
- CONTACT: Postel@USC-ISIF
-
- CSNET Mailbox Name Server Protocol (CSNET-NAMESERVER) --------------
-
- STATUS: Experimental
-
- SPECIFICATION: CS-DN-2
-
- COMMENTS:
-
- Provides access to the CSNET data base of users to give
- information about users names, affiliations, and mailboxes.
-
- Please discuss any plans for implementation or use of this
- protocol with the contact.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Transmission Control Protocol
-
- CONTACT: Solomon@UWISC
-
-
-
- Reynolds & Postel [Page 21]
-
-
-
- Official Protocols RFC 880
-
-
- Daytime Protocol (DAYTIME) -----------------------------------------
-
- STATUS: Elective
-
- SPECIFICATION: RFC 867
-
- COMMENTS:
-
- Provides the day and time in ASCII character string.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Transmission Control Protocol
- or User Datagram Protocol
-
- CONTACT: Postel@USC-ISIF
-
- Time Server Protocol (TIME) ----------------------------------------
-
- STATUS: Recommended
-
- SPECIFICATION: RFC 868
-
- COMMENTS:
-
- Provides the time as the number of seconds from a specified
- reference time.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Transmission Control Protocol
- or User Datagram Protocol
-
- CONTACT: Postel@USC-ISIF
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Reynolds & Postel [Page 22]
-
-
-
- Official Protocols RFC 880
-
-
- DCNET Time Server Protocol (CLOCK) ---------------------------------
-
- STATUS: Elective
-
- SPECIFICATION: RFC 778
-
- COMMENTS:
-
- Provides a mechanism for keeping synchronized clocks.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Internet Control Message Protocol
-
- CONTACT: Mills@USC-ISID
-
- SUPDUP Protocol (SUPDUP) -------------------------------------------
-
- STATUS: Elective
-
- SPECIFICATION: RFC 734 (in APH)
-
- COMMENTS:
-
- A special Telnet like protocol for display terminals.
-
- OTHER REFERENCES:
-
- DEPENDENCIES: Transmission Control Protocol
-
- CONTACT: Admin.MRC@SU-SCORE
-
- Internet Message Protocol (MPM) ------------------------------------
-
- STATUS: Experimental
-
- SPECIFICATION: RFC 759
-
- COMMENTS:
-
- This is an experimental multimedia mail transfer protocol. The
- implementation is called a Message Processing Module or MPM.
-
- Please discuss any plans for implementation or use of this
- protocol with the contact.
-
- OTHER REFERENCES:
-
- RFC 767 - Structured Document Formats
-
-
- Reynolds & Postel [Page 23]
-
-
-
- Official Protocols RFC 880
-
-
- DEPENDENCIES: Transmission Control Protocol
-
- CONTACT: Postel@USC-ISIF
-
- Network Standard Text Editor (NETED) -------------------------------
-
- STATUS: Elective
-
- SPECIFICATION: RFC 569
-
- COMMENTS:
-
- Describes a simple line editor which could be provided by every
- Internet host.
-
- OTHER REFERENCES:
-
- DEPENDENCIES:
-
- CONTACT: Postel@USC-ISIF
-
- Appendices
-
- Assigned Numbers ---------------------------------------------------
-
- STATUS: None
-
- SPECIFICATION: RFC 870
-
- COMMENTS:
-
- Describes the fields of various protocols that are assigned
- specific values for actual use, and lists the currently
- assigned values.
-
- Issued October 1983, replaces RFC 790 in IPTW, and RFC 820 of
- January 1983.
-
- OTHER REFERENCES:
-
- CONTACT: JKReynolds@USC-ISIF
-
-
-
-
-
-
-
-
-
-
- Reynolds & Postel [Page 24]
-
-
-
- Official Protocols RFC 880
-
-
- Pre-emption --------------------------------------------------------
-
- STATUS: Elective
-
- SPECIFICATION: RFC 794 (in IPTW)
-
- COMMENTS:
-
- Describes how to do pre-emption of TCP connections.
-
- OTHER REFERENCES:
-
- CONTACT: Postel@USC-ISIF
-
- Service Mappings ---------------------------------------------------
-
- STATUS: None
-
- SPECIFICATION: RFC 795 (in IPTW)
-
- COMMENTS:
-
- Describes the mapping of the IP type of service field onto the
- parameters of some specific networks.
-
- Out of date, needs revision.
-
- OTHER REFERENCES:
-
- CONTACT: Postel@USC-ISIF
-
- Address Mappings ---------------------------------------------------
-
- STATUS: None
-
- SPECIFICATION: RFC 796 (in IPTW)
-
- COMMENTS:
-
- Describes the mapping between Internet Addresses and the
- addresses of some specific networks.
-
- Out of date, needs revision.
-
- OTHER REFERENCES:
-
- CONTACT: Postel@USC-ISIF
-
-
-
-
- Reynolds & Postel [Page 25]
-
-
-
- Official Protocols RFC 880
-
-
- Internet Protocol on X.25 Networks ---------------------------------
-
- STATUS: Recommended
-
- SPECIFICATION: RFC 877
-
- COMMENTS:
-
- Describes a standard for the transmission of IP Datagrams over
- Public Data Networks.
-
- OTHER REFERENCES:
-
- CONTACT: jtk@PURDUE
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Reynolds & Postel [Page 26]
-
-